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delivered to the another network element. The protocol portion preferably is part of the protocol header. The protocol may be a 
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METHOD AND SYSTEM PROVIDING A MESSAGING SERVICE 



10- 



FIELD OF THE INVENTION 

The invention relates to a communication method and system 
implementing a messaging service 



BACKGROUND OF THE INVENTION 



Several networks provide messaging services which allow 
messages to be sent from one to another network terminal 

15 without necessity of actually initiating a call. For 
instance, a plurality of GSM networks support a short 
message service (SMS) which permits the transmission of 
short messages. A more recent development is the multimedia 
messaging service (MMS) which allows the transmission not 

20 only of text messages but also of pictures and the like. 
Both these SMS and MMS are store-and-f orward messaging 
services which necessitate additional network elements 
(e.g. SMSC, Short Message Service Center) and dedicated 
protocols such as specified in ETSI TS 23-040. 

25 

Moreover, the Internet provides a direct user-to-user 
messaging for chatting or instant messaging (e.g. using 
Instant Messaging/Presence Protocol IMPP) . Further, the 
Internet offers a store-and-f orward messaging, e.g. e-mail 
30 service (POP3 "Post Office Protocol, version 3" or IMAP4 
"Internet Message Access Protocol, Version 4") . 



Presently, some instant messaging services are either based 
on existing standards, or are proprietary solutions such as 
35 AOL instant messaging service. Some requirements of future 
instant messaging services are defined in IETF RFC 2778 and 
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RFC 2779. The instant messaging service requests both . 
sender and receiver to be on-line and registered to the 
instant messaging server. When the receiver is e.g. not 
reachable, no instant message can be delivered. 

For establishing a bidirectional connection between a 
caller and a callee, several call control protocols such as 
SIP {Session Initiation Protocol, see e.g. RFC 2543 and RFC 
2543bis) are proposed. SIP may not only be used as a call 
control protocol but also offers the possibility of being 
used as instant messaging service. For instance, the SIP 
INVITE message can be used to carry content payloads (MIME 
types such as JPEG) inside one- protocol message without the 
need of actually setting-up a voice-over-IP (VoIP) call. 
Other SIP message types (e.g. INFO) may also be used and 
new message types may be defined for this purpose- Note 
that the INVITE message is a signalling message. As. an 
example, a user A may include the following MIME-payloads 
into one INVITE message for the user B: 

- image/jpeg (e.g. to send a picture) 

- audio/midi (e.g. for playing a sound clip). 
All such information fits into one SIP message. 

Fig. 3 shows one example of using the INVITE message as a 
messaging possibility. The names and numbers of the 
messages shown in Fig. 3 are as defined in RFC 2543. First, 
user A sends an INVITE message (Fl) to user B which message 
includes the payload. User B responds by returning "100 
Trying" (F2) , "180 Ringing" (F3), and "200 OK" (F4), which 
confirms receipt of the message. User A then sends a "BYE" 
message (F5) , to user B which acknowledges this message by 
returning "200 OK" (F6) . 

SIP-based messaging provides the advantage of being usable 
without need of any new network elements and is therefore 
cheap, and may possibly replace other messaging services. 
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However, for performing this SIP-based messaging, both 
sender and receiver must be "on-line* 1 , i.e. user B must be 
actually reachable. 

5 

SUMMARY OF THE INVENTION 

The present invention aims at providing a messaging service 
which can easily be implemented without need of new network 
10 elements, and which offers enhanced messaging 
possibilities. 

The present invention provides a method and/pr system as 
defined in any one of the claims. Further, the invention 
15 provides network element adapted to perform the necessary 
functions. 

In accordance with one aspect of the invention, the instant 
messaging service is enhanced by providing a storing 

20 capability for messages. When the intended receiver of the 
message is presently unable to receive the message because 
he is e.g. not on-line, busy and/or not reachable by the 
network, e.g. by the proxy server of the receiving user, 
because of any other reason, the message may be stored, 

25 This saving of the message enables its later delivery to 
the receiving user when this user is able to receive the 
message, e.g. after re-attachment to the network. No 
connection for bi-directional communication needs to be 
established. 

30 

The protocol normally used for initiating a connection 
, . enabling e.g. a bi-directional communication between a call 
originating equipment and a call terminating equipment thus 
serves the further purpose of indicating whether or not 
35 transmitted instant messages are to be stored in case of 
impossibility of direct delivery. The protocol allowing 

3 
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messages to be sent from the sending to the receiving . 
equipment as part of the protocol, is amended so as to be 
able to include an identifier which may be or include a 
store command. The store command can be, in a preferred 
5 implementation a store-and-forward command, A serving 
network element trying to provide a connection to the 
receiving equipment in vain, is preferably adapted to check 
the protocol with respect to the inclusion of such an 
identifier representing a store command. When the store 
10 command is found, the message is not simply discarded but 

is stored in an appropriate place, such as in an own memory 
of this network element, or in a storage of another network 
element such as a server. 

15 As the identifier can be included in the protocol, the 
message and the identifier {e.g. store command) can be 
transmitted in a unidirectional manner from the sending 
equipment to the serving network element provided for 
establishing connections to the receiving equipment. This 

20 feature significantly reduces the signalling and traffic 
load necessary for transmitting and handling messages. In 
addition, no new protocols for messaging are necessary, and 
the invention can be implemented in existing networks in an 
inexpensive manner. Furthermore, no new network elements 

25 are necessary for implementing the invention, so that the 
disclosed technique is easily and inexpensively deployable 
by a network operator or service provider. This ^messaging 
service structure may also replace existing messaging 
services and hence contribute to a harmonisation of 

30 messaging services. 

The protocol preferably used is the Session Initiation 
Protocol SIP. The protocol comprises a portion allowing a 
network element, preferably the sending network element, to 
35 specify whether or not the message is to be stored, or 

stored-and-forwarded, by respectively setting or including 



OOCID: <WO Q207396A1J_> 



WO 02/07396 



PCT/EPOO/06708 



the identifier. This protocol portion is preferably part of 
the protocol header. The message receiving element which 
may be the serving network element serving the presently 
unreachable receiving network element, is able to easily 
5 check the protocol header with regard to existence of such 
a store, or store-and-forward, command, and will decide on 
storing or discarding of the message depending on the 
command included in the protocol header (if any) . 

10 The message is preferable sent in an INVITE request or in 
other SIP request sent from the sending to the receiving 
equipment. 

; Ut 
I _ i> 

When the command is a mere "store" command, the message 
15 will be stored, and the sending equipment will have to 

search for any stored messages, e.g. when re-attaching to 
the network. In case of a store-and-forward command, the 
system is adapted to automatically forward the message to 
the receiving equipment. This forwarding may e.g. be tried 
20 on a periodical basis, or may be performed when detecting 
that the receiving equipment can be reached again. 

The network element providing this storing, or storing-and- 
forwarding service may be a server such as a proxy server 
25 which is already provided as part of existing networks. 

In the following, further aspects, features and "advantages 
of the invention will be described with reference to some 
embodiments as shown in the drawings. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figs. 1 and 2 illustrate a preferred embodiment of a 
35 communication system in accordance with the invention; 

5 
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Fig. 3 shows the basic signalling messages between user 
equipments based on SIP; 

Figs. 4 and 5 show further examples of successful SIP to 
5 SIP messaging using two proxy servers; 

Fig. 6 illustrates the basic structure of a protocol word 
adapted in accordance with one implementation of the 
invention (based on SIP) ; 

10 

Fig. 7 shows a flow diagram illustrating an embodiment of a 
method according to the invention; and 

U . 

Fig. 8 shows a block diagram of an embodiment of a system 
15 in accordance with the invention, 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE 
INVENTION 

20 

Fig. 1 shows a first embodiment of the invention and 
illustrates a case where a message is to be sent from a 
first network element 1 (user A) to a second network 
element 3 (user B) . The network elements 1, 3 are, in the 

25 present embodiment , client or user equipments such as 

terminals- In the present example, the network element 1 
(user A) is an equipment trying to send a message (e.g. 
"MESSAGE user_b@sonera.com" addressed to user_b@sonera.com) 
to the receiving element 3 (user B) which is presently out 

30 of reach, e.g. switched-of f , busy, or located in a non- 
supported area, or the like. The connection request of 
network element 1 is handled by a network element 2 which 
may be a server (such as a proxy server) which provides 
e.g. CSCF (Call Server Control Function), and/or is a home 

35 location server which contains a database storing 

information on the present locations of network element 3 

6 
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and further network elements, reachability thereof, and the 
like. 

As shown in Fig. 1, the server 2 stores parameters for 
5 several users (user equipments) to be served by server 2. 
These parameters define the users profiles, network 
capabilities, and status of the users and terminals. For 
user B, the server 2 stores the inf ormation " out-of - reach"; 
"store-and-forward: notify"; "accepts: jpeg,gif", etc. This 

10 information may be updated by the server 2 or equipment 3 

e.g. when re-entering the serving area of server 2, or when 
equipment 3 wants to change or supplement the types of 
acceptable messages. The "accepts" field defines the types 
of acceptable messages. The field "store-and-forward" can 

15 be set by equipment 3, or by the operator or service 

provider of the network to "NO", "YES" , "NOTIFY" (when the 
sending user is to be notified after successful delivery of 
the message to the user B) ,r , "Forwarding Address or Service 
for forwarding messages", and the like. The operator or 

20 service provider may provide different storing services for 
different subscribers, such as no storing possibility for 
normal subscribers, and storing possibility for premium 
subscribers. 

25 The server 2 furthermore stores e.g. for user C the present 
IP address "172.3.2.2" for reaching user C, e.g.. via SIP. 
For user C, the field "store-and-forward" is set to "to e- 
mail" so as to forward any incoming SIP message to the e- 
mail address of user C. The server 2 preferably contains 

30 further information for users B, C and additional users 
served by this server. 

The network additionally contains a network element such as 
a server 4 used for storing any SIP message not promptly 
35 deliverable to the intended recipient. This server 4 is, in 
the present embodiment, not only used as a storing server 

7 
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but also as a forwarding server for actively forwarding any 
stored message to the recipient, e.g. periodically or when 
receiving information that the recipient is reachable 
again. 

5 

As mentioned above, in the example shown in Fig. 1, the 
user A is trying to send a message "MESSAGE 
USER_B@sonera.com" to user B using SIP. The SIP message is 
handled by server 2 which checks reachability of the 

10 recipient user B and detects that user B is presently out 
of reach. The server 2 then checks the contents of its 
database field "store-and-forward" set for user B, and 
detects the condition "notify" . Server 2 additionally 
checks the type of received message which, in the present 

15 example, may be a type "jpeg" . When this type of message is 
not comprised in the types mentioned in the field 
"accepts" , the message is discarded* Otherwise, server 2 
addresses server 4 for saving the presently undeliverable 
message received from user A. Hence, the SIP message is 

20 stored in the database of server 4 and waiting for later 
delivery to user B. 

Fig. 2 shows the embodiment of Fig. 1 in a condition where 
the user equipment 3 (user B) can be reached again'. When 

25 the user equipment 3 can be reached again, it will usually 
send a message signalling its present state or condition, 
e.g. its intention to receive access to the network. Such a 
message is shown in Fig. 2 as step 1.) and may consist in a 
request "register", "PDP context activation", or the like, 

30 depending on the type of network and the like. Such a 

request is addressed to server 2 which therefore recognises 
the reachability of equipment 3. When detecting this 
situation, the server 2 sends, in step 2.) of Fig. 2, a 
message "notify: user B is on-line" to server 4. The server 

35 4 checks its database with regard to any waiting message or 
messages stored for user B. When detecting such messages, 
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the server 4 sends this message or messages directly to 
user equipment 3 as shown in step 3.), "MESSAGE 
USER_BGsonera.com". The server 4 may also be adapted to 
send a confirmation to server 2 after successful 
transmission of the stored messages to user equipment 3. 
The server 2 then preferably sends, in step 4.), a message 
to user equipment 1 informing the latter on successful 
delivery of the message to user equipment 3, This message 
is shown in Fig. 2 as "NOTIFY A: contents has been 
received". .. . 

- - - - — • 

Furthermore, the server 2 changes the conditions set for 
user B from "out of reach" to e.g. the address of user B, 
and/or the field "store-and-forward" to "YES". In the 
latter case, any message received for user B during 
subsequent unreachability thereof will simply be stored and 
forwarded after later reachability of user B, without 
sending any "notify" message to user A such as shown in . 
step 4 . ) of Fig. 2. 

As illustrated in Fig. 2, the server 2 may meanwhile also 
have changed the contents of the fields for user C from "to 
e-mail" (Fig. 1) to "NO" based on information received from 
the equipment of user C or the network operator or service 
provider. 

The present invention therefore guarantees that the message 
contents (e.g. image or audio contents) of a SIP message is 
delivered to the receiver even if the receiver should be 
presently. out of reach or occupied. For achieving this 
function, the invention defines an extension to the syntax 
of a connection protocol such as SIP which allows the 
sender to define whether or not the message should be 
temporarily stored when the receiver should presently be 
out of reach, and should be sent to the receiver as soon as 
possible. This local temporary storage of the message is 
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performed taking account of the present status of the 
receiver. The storing place may be defined by the sender by 
adding a storing place address to the message . The storing 
place may also be defined by the serving server 2. 



10 



15 



20 



The standardisation drafts for SIP define that there may be 
a "request-disposition" header to specify caller 
preferences for the way how a server such as server 2 
should process a request. The header can include the 
following items: 



Request-disposition = 



proxy-feature 

cancel-feature 

fork-feature 

recurse-feature 

parallel-feature 

queue- feature 

ring-feature 



"Request-disposition" " : 11 

1# (proxy-feature I cancel-feature I 

fork-feature ! recurse-feature I 

parallel-feature | queue-feature 

ring-feature) 
= "proxy" | "redirect" 
= "cancel" I "no-cancel" 
= "fork" | "no-fork" 
= " recur se" | "no-recurse" 

"parallel" I "sequential" 
- "queue" | "no-queue" 

"ring" I "no-ring" 



The invention extends this header to specify also "do-not- 
25 store" and "store-and-forward-if-not-reached", and the 
like. 



"Do-not-store" means that this message should not he 
stored (e.g. it is instant in nature) . "Store-and-f orward- 

30 if-not-reached" means that this message should be stored, 
in a place defined by the sender, since it is important. 
E.g. if receiver was out-of-reach, this message is stored 
temporarily and sent to the receiver afterwards, as soon 
as possible. Usually local proxy (or e.g. yahoo like of 

35 proxy) will be the storing place. That proxy will be 
subscribed to presence status service and waits for a 
receiver to become on-line. When the receiver becomes on- 
line, the proxy gets a notification, and sends the message 
to the receiver. After 200 OK message, the proxy also 
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(optionally) notifies the original sender that "Message 
has been delivered", using SIP NOTIFY method. 

The above-described implementation ensures correct delivery 
5 to the receiver as soon as same is reachable again, e.g. 
after re-attaching to the network or terminating any 
ongoing call. 

Fig. 4 shows a basic example of a SIP call performed when 
10 trying to establish a bi-directional media connection "Both 
way RTP media". The example of Fig. 4 shows a successful 
SIP to SIP connection between users A and B through two 
proxy servers, proxy 1 and proxy 2. The numbering Fl to F23 
attached to the steps of Fig. 4 indicate the flow sequence 
15 whereas the words or numbers in front of this step 

numbering are in line with the definition of the SIP 
protocol. As the message flow and sequence steps of Fig. 4 
are self-explanatory, no more detailed description is 
necessary. 

20 

When, in accordance with the .above-described embodiments, 
SIP is used for messaging, no "both way RTP media" is set- 
up. The flow may therefore proceed, in accordance with one 
embodiment of the present invention, as shown in Fig. 5. 
25 There are several flow possibilities to achieve SIP-based 
messaging. 

The INVITE request message sent in step F4 of Fig. 5 
contains the message payload (MIME types) sent from user A 
30 to user B. 

In the following, one example of the INVITE request from 
user A to proxy 1 is shown: 

35 

F4 INVITE A -> Proxy 1 

11 



XWO. <WO 02C7396A1_I_> 



WO 02/07396 PCT/EPO 0/06 708 



5 INVITE sip: UserBGssl. wcom.com SIP/2.0 

Via: SIP/2. O/UDP here.com: 5060 
From: BigGuy <sip:UserA@here.com> 
To: LittleGuy <sip: UserB@there. com> 
Call-ID: 12345601@here.com 
10 CSeq: 1 INVITE 

Contact: BigGuy <sip: UserA(?here . com> 
Authorization: Digest username="UserA", realm="MCI 
WorldCom SIP", 

nonce= n wf 84f Iceczx41ae6cbe5aea9c8e88d359" , opaque= ,,,, / 
1 5 uri= " sip : ss 1 , wcom. com" , 

response="42ce3cef44b22f50c6a6071bc8" 
Content-Type: multipart/mixed; 

boundary=gc0pJq0M: 08 jUS34c0p 
Con tent -Length: 147 

20 

v=0 

o=UserA 2890844526 2890844526 IN IP4.here.com 
s=Session SDP 
c=IN IP4 100.101.102.103 
25 t=0 0 

m=audio 4 9170 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 

_=_Next Pa rt_gcOp JqOM :08jU534cOp 

30 Content-Type: image/ jpeg; charset="iso-8859-l" 



ROlGODlhuQEFAf AAAAAAAP// /yH5BAEAAAEALAAAAAC5AQUBAAL+j I+py+0 
P4wKUyouz3rz7D4biSJZmUAEnl7ZW51brTNf2jec6FrvKC+sJhz0IMcWQ7Z 
35 bMpvO5O01RVKnliMlqt9wuFwoOi8dkr/mMTqu35Lb7DRet5/S6nRjP6/d8w 
/OPGOjVRlhoyCSYqLgIdOj4CBnCOElJF3mJmRlRydn5pQkamnnlWWqqJJqq 
anjaaroKG5vnSlspe4tbVrsrmOv7+8QrXAdcbIwzNaw8eNzsvLQcjfRMXW0 
jvWytvWIC 



If there is more than one payload 

in SIP, then multiparty MIME is used, as shown in the above 
45 example (Content-Type: multipart/mixed; 

boundary=gc0pJq0M:08jU534c0p) . In the payload itself there 
are different MIME-types, separated by boundary. 

If user B is not reachable then the immediate sending 
50 fails. 
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In order to have a store and forward service in accordance 
with the invention, several possibilities are described 
below. 

5 1. Using the SIP forward capabilities: 

User B has a "forwarding on not reachable" activated at 
proxy 2 {which may correspond to server 2 of Figs. 1, 2) . 
If User B can not be reached by proxy 2 then the proxy 2 
forwards the message to the user's B "ghost user agent" B2, 

10 which can be a "connected" device which is always reachable 
/ online, such as server 4. Then user agent B2 periodically 
tries to forward the message {using the same SIP based 
messaging capabilities) to the User agent Bjot the user B. 
The periodical forwarding timer can be of any kind* It may 

15 also be provided that the user agent B2 tries to forward 
the message only for a certain time and then discards it. 

2. Forwarding the message payload to the user's B e-mail 
address: 

20 If user B is not reachable by the proxy 2, then proxy 2 

transfers the message payload (MIME type) to the user's B 
e-mail address (e.g. with SMTP) which may be specified in 
the INVITE message or which may be contained in a user 
profile option used by proxy 2. 

25 

3. Forward to MMS server: 

Same as in 2, but the message payload (MIME types) is 
forwarded to a MMS server. MMS stands for Multimedia 
Messaging Service as defined in 3GPP 22-140 and 23.140. The 
30 message is delivered when user B becomes reachable by the 
MMS server. This can be part of the user's B profile. 

4. Forward to SMSC: 

Same as in 2, but the text part of the message (MIME type 
35 TXT) is forwarded to the SMSC (Short Message Service 

13 
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Centre) . The message is delivered when user B becomes 
reachable by the SMSC. This may be also part of the user's 
B profile. 

5 Fig. 6 shows an example of a basic structure of a SIP '\ 
protocol word adapted in accordance with the present ^ 
invention. The protocol word contains a header 11 which, iff 
accordance with the invention, includes a "store command" 
field (as part of the protocol word) . The "store command" 
10 field represents or includes an identifier which may be 

set, by the sender of the message, to the settings "store", 
"store-and-forward", "notify", or "do not store". The 

protocol word furthermore contains a message* jport ion 12 

u 

containing a message e.g. of MIME type, and the usual end 
15 field 13. 

In this example, a SIP INVITE message is used for carrying 
the payload, wherein the payload is inserted into the MIME 
field 12. When the receiving user B has activated 

20 "forwarding on not reachable" in his/her proxy server 2, 

the proxy server 2 will forward any received SIP message to 
a network element such as network element 4 (ghost user 
agent) which is a device always connected to the proxy 
server. The proxy server 2, or the server 4 may be adapted 

25 to periodically try to forward any stored message (using 

SIP) to the user equipment 3. A maximum lifetime period can 
be defined for undelivered messages saved in the storing 
network element such as server 4 . Upon expiry of the 
lifetime period, stored undelivered messages will be 

30 cancelled. . ; 

As discussed above, the message payload may also be re- 
addressed to another address when the receiving user should 
not be reachable or occupied or the like, and may be 
35 addressed e.g. to the e-mail address (see the parameters 
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15 



20 



25 



30 



stored for user C in Fig. 1), a MMS server, a SMSC, or the 
like. 

Fig. 7 shows a flow chart illustrating method steps 
executed in an embodiment of the invention. Steps 701 to 
703 may be executed in a sender which may be the user 
equipment 1 of user A. In step 701, a messaging (i.e. no 
signalling) message to be sent is received which message 
may be input by a user via a terminal such as keyboard, 
digital camera and the like. On some embodiments message is 
received from another network element such as a messaging 
gateway acting as a gateway between the messaging system of 
the SIP based network and the WAP service centers connected 
to the GSM network. An identifier is included into, or 
added to, the message in step 702. The message and the 
identifier may be included into a protocol word such as 
SIP. Thereafter the message is sent in step 703. The sent 
message will be received, in step 704, by the addressed 
network element such as server 2 of Fi-gs. 1, 2. 

The reachability of the recipient indicated in the message 
or transmitting protocol is checked in steps 705 and 706. 
When the recipient is reachable, the message is sent to the 
recipient in step 707. When, to the contrary, the recipient 
is presently not reachable, e.g. busy or de-attached from 
the network, the process proceeds to step 708 where the 
identifier of the received message is checked ih order to 
decide on the temporary storing (step 709) of the message 
in an internal or external memory, e.g. in server 4, or 
immediate discarding of the message (step 710), depending 



on the status of the identifier. The status of the 
identifier may e.g. have the value "00" for storing, "11" 
for discarding, "01" for "Notify sender after delivery to 
the Recipient and the like. 
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When a message is stored, the step 705 may be repeatedly 
executed until reachability of the sender is detected. The 
step 705 may additionally or alternatively be triggered 
e.g. when the recipient attaches again to the network- When 
5 reachability is found, the stored message is read out of 

the memory, and is sent to the recipient, e.g. from server 
A or 2. 

Fig. 8 shows a block diagram of network elements of an 
10 embodiment of a system according to the invention. A sender 
80 includes a receiving means 801 for receiving a messaging 
(i.e. no signalling) message (user traffic) to be sent, and 
is adapted to execute step 701 of Fig. 7. The message may 
be input via a terminal such as keyboard, digital camera 
15 and the like, or from another network element. The sender 
80 further comprises an including means 802 for adding, or 
including, an identifier into the message, and eventually 
including the message into one or more protocol words of a 
messaging enabling protocol such as SIP, so as to carry out 
20 step 702. A sending means 803 is adapted to execute step 
703, i.e. to send the protocol word(s) including the 
message and the identifier to a serving network element 81 
such as server 2. 

25 The serving network element 81 is adapted to carry out the 
steps 704 to 710 shown in Fig. 7. The serving network 
element comprises a receiving means 811 for receiving 
messages, e.g. the protocol word(s) sent from sender 80, 
and a reachability checking means 812 which checks whether 

30 the intended recipient 82 can be accessed so that the 

message can be promptly delivered to the intended recipient 
82. If yes, the message is sent to a sending means 813 of 
the serving network element 81. The sending means 813 sends 
the message to the indicated receiving address, i.e. to the 

35 recipient 82. 
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When the checking means 812 detects that the recipient 81 
can presently not be reached , it transfers the message to a 
checking means 814 which is adapted to check whether the 
message is to be stored or discarded. The checking means 
5 814 performs this check by examining the identifier 
included in the message or protocol word. When the 
identifier does not command a storing of the message, the 
message is discarded by a discarding means 816 which e.g. 
actively deletes the message or simply inhibits a storing 
10 thereof. Otherwise, when the identifier commands the 

storing of the message if not promptly deliverable, the 
checking means 814 sends the message to a storing means 815 
which may be an internal memory or an external storage such 
as in server 4. 

15 

When the checking means 812 subsequently detects that the 
recipient 81 may be reached again, it either retrieves the 
stored message from the storing means 815 and transfers the 
message to the sending means 813, or instructs the storing 
20 means 815 to transmit the message to the recipient 81 via 
other means, e.g. server 4. 

According to one embodiment of the invention, the header 
11, in particular, the Request-Disposition part, of the SIP 

25 protocol word is newly defined so as to include an 

identifier, preferably the protocol portion "store command 
field" which may contain the commands "do-not-store" or 
"store-and-forward-if~not-reached" according to the setting 
of user A. The first header "do-not-store" informs the 

30 system that the message is of instant nature and is to be 

discarded instantly if it cannot be promptly delivered. The 
latter header "store-and-forward-if -not-reached" means that 
the message should be stored (usually in the local proxy or 
another storage) and forwarded, if the receiving equipment 

35 is presently unreachable or occupied, or the like. The 

proxy will be subscribed to a present status service for 
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being informed on the presence status, and will wait for 
the receiver to become on-line. As shown in Fig. 2, the 
proxy server 2 is adapted to send a notification (step 4) 
to the original sender 1 using SIP NOTIFY method, after the 
5 delivery of the message to the user B (200 OK message) . 

When the receiving user B is becoming on-line again f the 
network recognises -this situation, e.g. by receiving a SIP 
REGISTER message or PDP-context activation request. The 
10 CSCF and home location server 2 inform the SIP store and 
forward server 4 about this situation, either using a SIP 
protocol or any other protocol. The servers 2 and 4 may be 
also be co-located inside the same machine. ■) 

15 Although preferred embodiments of the invention have been 
described above, the invention is not limited to the 
details thereof. Instead of SIP protocol, any other instant 
messaging protocol can be used provided it is no specific 
protocol intended only for messaging service but a protocol 

20 primarily intended for establishment of connection between 
two (or more) terminals. 
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CLAIMS 

5 

1- Communication system comprising a plurality of 
network elements, wherein a connection from a first network 
element to a second network element can be established using 
messages according to a protocol , which protocol also allows 
10 the sending of a messaging message between a sender and a 
recipient, wherein at least one message according to the 
protocol includes an identifier specifying whether or not the 
message is to be stored in case it cannot be promptly 
delivered to the recipient. 

15 

2, Communication system according to claim 1, wherein a 
message according to the protocol comprises a protocol header 
and the identifier is part of the protocol header. 

20 3. Communication system according to claim 1, wherein 

the identifier is an extension field in a message according 
to the protocol. 

4 . Communication system according to any of the 

25 preceding claims, wherein the connection is bi-directional. 

5. Communication system according to any one of the 
preceding claims, wherein the protocol is a Session 
Initiation Protocol (SIP) . 

30 

6. Communication system according to claim 5, wherein 
the message is contained in an Invite request. 

7. Communication system according to claim 5, wherein 
35 the message is contained in an INFO message. 
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8. Communication system according to any one of the 
preceding claims, comprising a server for storing the 
message. 

5 9. Communication system according to claim 8, wherein 

the server is a server for storing and forwarding the 
message. 

10. Communication system according to any -one of the 
10 preceding claims, comprising a serving network element for 

transmitting the message from the sender to the recipient, 
the serving network element being adapted to control the 
storing of the message in case the recipient is presently 
unreachable, to detect a subsequent reachability of the 
15 recipient, and to initiate the forwarding of the stored 

message to the recipient when detecting the reachability of 
the recipient. 

11. Communication system according to claim 8, 9 or 10, 
20 wherein the server is a proxy server of the recipient. 

12. Communication system according to any of claims 8 to 

11, wherein the server is adapted to periodically try to send 
the stored message to the recipient. 

25 

13. Communication system according to any of claims 8 to 

12, wherein the server is adapted to forward the message to 
another address indicated in a database of the server or 
another network element, or in the protocol. 

30 

14. Communication system according to any one of the 
preceding claims, wherein a store-and~forward command can be 
set in the identifier. 

35 15. A method to be performed in a communication system 

20 
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comprising a plurality of network elements, wherein a 
connection from a first network element to a second network 
element can be established using at least one message 
according to a protocol which also allows the sending of a 
5 messaging message between a sender and a recipient, wherein 
an identifier specifying that the message is to be stored in 
case it cannot be promptly delivered to the recipient is 
included in at least one message according to the protocol, 
and the message is stored if it cannot be promptly delivered 
10 to the recipient. 

16. Method according to claim 15, wherein the message is 
stored in a server. 

15 17. Method according to claim 16, wherein the server is 

a server for storing and forwarding the message- 

18. Method according to any one of claims 15 to 17, 
wherein a serving network element controls the storing of the 
20 message in case the recipient is presently unreachable, 
detects a subsequent reachability of the recipient, and 
initiates the forwarding of the stored message to the 
recipient when detecting the reachability of the recipient. 

25 19. Method according to claim 16, 17 or 18, wherein the 

server is a proxy server of the recipient. 

20. Method according to claim 16, 17, 18 or 19, wherein 
the server is adapted to periodically try to send the stored 

30 message to, the recipient. 

21. Method according to any of claims 16 to 20, wherein 
the server is adapted to forward the message to another 
address indicated in a database of the server or another 

35 network element, or in the protocol. 



21 



XXtD: <WO__ae07396A 1 J_> 




WO 02/07396 



PCT/EP00/06708 



22. Method according to any one of claims 15 to 21, 
wherein a store-and-f orward command can be set in the 



identifier. 



5 



23. A network element for a communication system 
comprising a plurality of network elements , wherein a 
connection from a first network element to a second network 
element can be established using at least one message 

10 according to a protocol which also allows the sending of a 
messaging message from a sender to a recipient, wherein the 
network element is adapted to include in at least one message 
according to the protocol an identifier specifying that the 
message is to be stored in case it cannot be promptly 

15 delivered to the recipient. 

24 . A network element for a communication system 
comprising a plurality of network elements, wherein a 
connection from a first network element to a second network 

20 element can be established using at least one message 

according to a protocol which also allows the sending of a 
messaging message from a sender to a recipient, wherein the 
network element is adapted 



25 message including an identifier specifying that the message 
is to be stored in case it cannot be promptly delivered to 
the recipient, and 

to store the message if it can not be promptly delivered 
to the recipient. 



to receive a message according to the protocol, the 



30 
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